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@ Coprocessor management In e virtual memory virtual machine data processing system. 
@ Management of (he operation of a coprocessor in a virtual 
memory virtual machine data processing system in which an 
Input/Output channel and an Input/output channel controller 
Interconnect the coprocessor to the main processor and 
system memory uses a Virtual Rosource Manager (VRM) 
comprising a group of interrelated software programs which 
function In the system to establish virtual machines that 
execute application programs concurrently. A Coprocessor 
Manager component of the VRM establishes a Virtual Machine 
In which the coprocessor executes application programs that 
cannot be executed on the main processor. The coprocessor is 
mounted on an integrated circuit card which is Inserted Into a 
'mother board' socket which contains the main processor and 
related components. 
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Description 

COPROCESSOR MANAGEMENT IN A VIRTUAL MEMORY VIRTUAL MACHINE DATA PROCESSING SYSTEM 



The present invention relates to coprocessor 
management in a virtual memory virtual machine 
data processing system. 

U.S. Application. Serial No. 6-706803, filed on 
2-28-85 in the name of P.A. Buckland. et al. entitled 
"Logical Arrangement for Controlling Use of Differ- 
ent System Displays by Main Processor and Copro- 
cessor," and assigned to the assignee of the present 
invention, discloses a logical arrangement for the 
coprocessor of a data processing system to share a 
number of display devices with the main processor. 

U.S. Application, Serial No. (AT9-85-018). filed on 
1-17-86, in the name of Duval, et al, entitled 
"Handling of UNIX (trademark of AT&T) Read and 
Write System Calls for Mapped Files' and assigned 
to the assignee of the present invention, discloses a 
page segmented virtual memory data processing 
system which establishes virtual machines that 
operate "concurrently" to process different applica- 
tion programs. 

The prior art discloses various data processing 
system in which a processor Is employed in the 
system to assist the main processor In the process- 
ing of Information. Generally, the coprocessor is a 
special type of processor that excels in performing a 
specific data processing task, such as floating point 
arithmetic, which could be relatively time-consuming 
on a more general purpose type processor. 

In other systems, the coprocessor is treated as an 
equal, and certain protocols and algorithms are 
established to control the operation of each proces- 
sor In a manner to ensure that the various 
applications that are being run by both processors 
do not interfere with each other. 

The prior art also discloses a number of virtual 
memory virtual machine data processing systems in 
which a Virtual Resource Manager establishes a 
virtual machine that operates to execute particular 
applications "concurrently," in that the system 
processor or system resources are shared in a time 
multiplex fashion among the various virtual ma- 
chines. 

While these prior art arrangements operate satis- 
factorily, they do not provide a solution to a problem 
that is often faced by the designer of data process- 
ing systems and users, where a new system is 
introduced with a new operating system for which 
there are no existing application program. The 
problem involves providing a translation or migration 
path to permit a customer to continue to run existing 
programs on the new system and to add new 
application programs as they are developed, to 
either provide new function or enhancements to the 
old applications. 

When the new system is not upward program 
compatible with the customer's existing system and 
programs, only two practical options exist if the 
customer wants to take advantage of the enhance- 
ments of the new system. The first option is to run 
both the systems while converting all of the old 
programs to the new environment. The second 



option is to attempt to emulate the old programs on 
the new machine, which generally results in less than 
optimum performance on the new system. 

The present invention provides a relatively econ- 
omical way to solve the above-described problem. 

From one aspect, the present Invention provides a 
method for managing the operation of a coproces- 
sor in a virtual memory virtual machine data 
processing system which includes a Virtual Re- 
source Manager (VRM) consisting of a plurality of 
interrelated programming components which are 
executed on the main processor to establish virtual 
machines for executing various application pro- 
grams concurrently, the VRM assigning system 
resources, including one of a plurality of operating 
systems, to each of the virtual machines, including 
establishing, in the VRM. a coprocessor programm- 
ing subsystem component comprising a plurality of 
programming subcomponents which function to 
define a virtual machine interface to the coprocessor 
and executing the subsystem component to permit 
the coprocessor to process an application program 
under the control of an operating system that is run 
by the main processor. 

From another aspect, the present invention 
provides a virtual memory virtual machine data 
processing system which includes a main proces- 
sor, a coprocessor, a Virtual Resource Manager 
(VRM) consisting of a plurality of interrelated 
programming components which are executed on 
the main processor to establish virtual machines for 
executing various application programs concurren- 
tly, the VRM assigning system resources, including 
one of a plurality of operating systems, to each of the 
virtual machines, including establishing, in the VRM, 
a coprocessor programming subsystem component 
comprising a plurality of programming subcompo- 
nents which function to define a virtual machine 
interface to the coprocessor and executing the 
subsystem component to permit the coprocessor to 
process an application program under the control of 
an operating system that is run by the main 
processor. 

As disclosed . hereinafter, a data processing 
system Is established which comprises a main 
processor connected to a system memory through a 
memory manager unit and a coprocessor which is 
attached to the input/output bus of the system 
which, in turn, Is connected to the main processor 
through an input/output channel controller. The 
coprocessor has an architecture that is functionally 
identical to the prior art system processors, thereby 
permitting current existing application programs to 
be run on the coprocessor. The system is provided 
with a suitable set of programs, referred to as a 
Virtual Resource Manager (VRM), to establish a 
virtual machine type environment in which a number 
of different operating systems are available to be run 
on the virtual machines that are established by the 
VRM. These virtual machines generally share the 
system processor, but one virtual machine can be 



2 



3 o: 

configured, which employs the coprocessor along 
with other system resources, thus permitting the 
system to run all existing programs and take 
advantage of any other high function components 
such as displays, printers, etc., that may be 
associated in the new system. 

The present invention will be described further by 
way of example with reference to an embodiment 
thereof as illustrated in the accompanying drawings 
In which:- 

Fig. 1 is a schematic illustration of a virtual 

memory data processing system; 
Fig. 2 illustrates the interrelationships of the 

Virtual Resource Manager (VRM) shown in 

Fig. 1 to the data processing system and a 

virtual machine; 

Fig. 3 is a detailed block diagram of the data 

processing system shown In Fig. 1; 
Fig. 4 illustrates the relationships between 

the coprocessor's subsystem and the rest of 

the I/O subsystems (lOs); and 
Fig. 5 illustrates the coprocessor event block 

data structure. 
As shown in in Fig. 1, the system comprises a 
hardware section 10 and a software or programming 
section 11. Hardware section 10, as shown, com- 
prises a processor function 12, a memory manage- 
ment function 13, a system memory function or RAM 
14. system bus 15. an Input/Output Channel Control- 
ler (IOCC) 16, and an Input/Output bus 21. The 
hardware section further Includes a group of I/O 
devices attached to the I/O bus 21 through the IOCC 
16, including a disk storage function 17, a display 
function 18,a coprocessor function 19, and block 20, 
representing other I/O devices such as a keyboard 
or mouse-type device. 

The program section of the system includes the 
application program 22 that is to be run on the 
system, a group of application development pro- 
grams 23, or tools to assist in developing new 
applications, an operating system kernel 24, which, 
for example, may be an extension of the UNIX 
system V kernel, and a Virtual Resourco Manager 
program 25, which functions to permit a number of 
virtual machines to be created, each of which is 
running a different operating system, but sharing the 
system resources. The system may operate, there- 
fore, in a multi-tasking, multi-user environment 
which is one of the main reasons for requiring a large 
virtual memory type storage system. 

Fig. 2 illustrates the relationship of the Virtual 
Resource Manager 25 to the other components of 
the system. As shown in Fig. 2, a virtual machine 
includes one or more application programs such as 
22a-22c and at least one operating system 30. A 
virtual machine interface 31 is established between 
the virtual machine and the VRM 25. A hardware 
interface 32 is also established between the VRM 25 
and the hardware section 10. The VRM 25 supports 
virtual memory. It can be assumed, for purposes of 
explanation, that the memory capabilities of the 
hardware shown In Fig. 1 includes a 24 bit address 
space for system memory 14, which equates to a 
capacity of 16 megabytes for memory 14, and a 40 bit 
address space for virtual memory, which equates 
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to 1 terabyte of memory. A paged segmentation 
technique Is implemented for the Memory Manage- 
ment Unit 13, so that the total virtual address space 
is divided into 4,096 memory segments, with each 

5 memory segment occupying 256 megabytes. 

The details of the arrangement, as shown in Figs. 1 
and 2 including the various data structures that are 
employed by the Virtual Resource Manager, are set 
forth in detail in co-pending applications, (Serial No. 

10 AT9-85-018) which is incorporated herein by ref- 
erence. 

Fig. 3 is a detailed block diagram of the system 
shown in Fig. 1 . As shown, the system comprises a 
main Central Processing Unit 12, a memory control- 

15 ler 13, a Read Only Storage block 13a, and a refresh 
charge block 13b. A portion of an Input/Output 
Channel Controller Is shown in block 16a. The 
functional blocks are depicted as being mounted on 
a printed circuit card 35, referred to as the processor 

20 card. The processor card is arranged to be inserted 
In a pair of sockets on a mother board which 
contains sockets for other cards, functional modules 
such as the refresh control 34, the interrupt 
controller 42, the Direct Memory Access controller 

25 43, a communications controller 41 , and a keyboard 
controller 40. The mother board also mounts the 
other portion 16b of the Input/Output Channel 
Controller function in addition to being provided with 
a number of multi-conductor buses which carry 

30 signals throughout the system. The two main buses, 
shown In Fig. 1, are the I/O bus 44 and the memory 
bus 27, which extend from the memory controller on 
the processor card to the RAM memory 14 on the 
memory card. 

35 The system shown in Fig. 3 further Includes three 
additional cards, 46, 47, and 48, which are plugged 
into the mother board and are attached to the I/O 
bus 44. Card 46 is designated as the coprocessor 
card and Includes the second processing unit in the 

40 system, which Is referred to as the coprocessor. The 
coprocessor card 46 may be assumed to be 
functionally equivalent to the IBM PC/AT Micropro- 
cessor System. Cards 47 and 48 are display adapter 
cards, whose primary function Is to act as a 

45 conventional video buffer for display devices 49a and 
49b. It should be assumed that a reference in this 
description to a display or display unit encompasses 
both the tube that is the screen, and the associated 
electronics included within the video buffer to 

50 achieve the display function. The additional electro- 
nics provided on the adapter card Includes such 
things as a display controller which comprises a 
number of registers for controlling various display 
parameters, etc., all of which are standard controls 

55 for the display devices. 

The details of the system shown in Fig. 3 are set 
forth In the cross-referenced application (Serial 
No. 6-706803), which is also Incorporated herein by 
reference. 

60 Fig. 4 shows the relationship between the copro- 
cessor subsystem components and the rest of the 
system. 

The coprocessor VRM subsystem consists of the 
Coprocessor Manager 50. the Coprocessor Device 
65 Driver 51, the Coprocessor Virtual Terminal 52, the 
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Coprocessor Async. Emulation Device Driver 53. 
and the Coprocessor Only Device Driver 54 subcom- 
ponents. A virtual machine can configure and start 
the coprocessor by issuing the appropriate Define 
Code and/or Define Device Supervisor Call (SVCs) 
to load the define the various coprocessor subcom- 
ponents to VRM. Configuration Information is then 
passed to the Coprocessor Manager in the form of 
Send Command SVCs. The device options field in 
the Send Command SVC is used to request the 
various services provided by the Coprocessor 
Manager. The configuration information consists of: 

- the amount of memory to be allocated to the 
coprocessor 

- minidisks to be attached to the coprocessor 

- system display(s) usage (access, mode) 

- adapter cards to be attached to the coprocessor 

- logical association of communication ports to 
communication adapters 

- whether or not the user is to be informed of 
coprocessor accesses to unallocated devices 

The Coprocessor Manager allocates the memory 
required, copies the BIOS and ROM BASIC Into 
write protected memory and attaches to the speci- 
fied devices. It then initialises and starts the 
coprocessor. The virtual machine must be able to 
handle unsolicited Interrupts from the coprocessor 
VRM component to terminate the coprocessor 
environment or to inform the user of coprocessor 
accesses to devices that it does not own. It must 
also issue a terminate command to the Coprocessor 
Manager before deleting any of the coprocessor 
subcomponents from VRM. With the hardware 
support provided on the coprocessor card, the 
coprocessor is easily prevented from accessing 
devices that are not allocated to it. However, the 
processor 12 does not have the ability to block off 
I/O ports, so the device drivers must respect any 
allocation to the coprocessor. Any time both 
processors attempt to access the same device, the 
results are unpredictable. 

The Coprocessor Device Driver controls the 
coprocessor by appropriately setting registers on 
the coprocessor card, by responding to Interrupts 
generated by the coprocessor card, and by standard 
mechanisms for dealing with memory and the VRM 
I/O Subsystem. 

FUNCTIONAL CHARACTERISTICS 

The coprocessor VRM component manages the 
coprocessor environment. It establishes the con- 
figuration and handles routing among the coproces- 
sor VRM components and the operating system 
component. Only one virtual machine can attach to 
the Coprocessor Manager at a time. Although it is 
dependent on code running in the operating system 
in a virtual machine, it is not dependent on a 
particular operating system. An application running 
in any operating system on the VRM can start and 
run the coprocessor provided that it meets certain 
interfaces and expectations: 

- The application must provide the user interface for 
starting, stopping, and configuring the coprocessor 
environment and devices. 

- The coprocessor VRM component is not part of the 



base VRM therefore It must be Installed from above 
the the operating system. 

- The coprocessor must be configured by using the 
configuration services provided by the Coprocessor 

5 Manager. 

- The application must open a virtual terminal for the 
coprocessor (this is required even if the coproces- 
sor drives the display directly). 

- The application must be able to accept and handle 
10 return codes from these calls. 

-The application must accept virtual interrupts from 
the coprocessor VRM component. 

The coprocessor VRM component consists of the 
following subcomponents. 
15 - Coprocessor Manager (CPM) 50 

- Coprocessor Virtual Terminal (CFVT) 52 

- Coprocessor Device Driver (CPDD) 51 

- Coprocessor Async. Emulation Device Driver 
(CPADD) 53 

20 - Coprocessor Only Device Device Driver (CPODD) 
54 

which are not to be confused with processes or 
programs. Each of these pieces may contain more 
than one VRM process and is composed of several 
25 routines (some of which run synchronously with the 
caller). 

COPROCESSOR MANAGER 
The Coprocessor Manager is a VRM device 

30 manager that Is responsible for handling the copro- 
cessor card. In addition to providing device manager 
functions for the Coprocessor Device Driver, the 
Coprocessor Manager attaches to devices In the 
name of the coprocessor. All dedicated devices that 

35 the coprocessor uses must be attached by the 
Coprocessor Manager. This attachment not only 
prevents a virtual machine from using the device, it 
also prevents the VRM device driver from accessing 
that device. Shared devices must be managed by the 

40 Coprocessor Manager through the appropriate VRM 
services (e.g., disk requests are routed through the 
Minidisk Manager). The Coprocessor Manager pro- 
vides the following functions: 

- accepts commands from the virtual machine to 
45 start, stop, and configure the environment and 

devices 

- accepts status from the Coprocessor Device Driver 
concerning errors and functions to be performed 

- interrupts the virtual machine to report errors 
50 - owns devices, making them unavailable to the 

virtual machine 

- terminates the coprocessor and releases all 
resources 

55 COPROCESSOR VIRTUAL TERMINAL 

The coprocessor virtual terminal mode processor 
is responsible for creating and maintaining the virtual 
terminal for the coprocessor. It utilises the VDD 
(Virtual Display Driver) interface to set keyboard 

60 mode indicators, bind appropriate display second 
level interrupt handles, select a display for the 
coprocessor virtual terminal, and to emulate PC 
Monochrome and PC Colour Graphics modes on 
non-PC displays. Providing display management and 

65 processing of keyboard input, It Is the second type 
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of mode processor handled in the VRM. the primary 
being High Function Terminal (HFT). The only 
Interface factor that distinguishes the coprocessor 
virtual terminal from other mode processors, In the 
eyes of the VRM, is that the code already exists (a 
module copy does not have to be performed by the 
VTRM). The functions it provides are: 

- allocates a relocated video buffer and passes the 
address to the coprocessor card to write to when It 
does not own the display. 

- allocates a video queue and a display conversion 
buffer (graphics only) when emulating PC Mono- 
chrome or PC Colour Graphics modes on e non-PC 
display. 

- receives keyboard position codes from the key- 
board device driver and converts them to PC or PC 
AT scan codes to pass t the Coprocessor Device 
Driver. 

- receives notification from the Coprocessor Device 
Driver to update a non-PC display adapter. The 
Coprocessor Virtual Terminal will then make the 
appropriate calls to the VDD (Virtual Display Device 
Driver). 

- receives VTRM queue elements to activate /deacti- 
vate/close the virtual terminal process by restoring/ 
saving the state of the display. 

- receives notification from the Coprocessor Device 
Driver to change the keyboard mode and to toggle 
the keyboard LEDs. 

COPROCESSOR DEVICE DRIVER 

The Coprocessor Device Driver handles the 
coprocessor card, it does not handle any other 
devices that the coprocessor uses. The functions it 
provides are: 

- resets and initialises the coprocessor card to a 
predetermined state. All addresses are trapped and 
emulated until the Coprocessor Manager or the 
Coprocessor Virtual Terminal requests that the 
addresses be released. 

- fields the following interrupts from the coprocessor 
card: 

- Interrupt when the coprocessor has been stopped 

- interrupt due to an I/O Trap 

- interrupt due to a relocated video buffer write 

- interrupt for video queue full/video warning 

- interrupt when the coprocessor tried to access the 
system speaker 

The Coprocessor Device Driver will collect the 
information regarding the interrupt and then process 
the interrupt Off Level (i.e., the coprocessor inter- 
rupt is reset before the interrupt is actually pro- 
cesses - this allows other device interrupts to be 
processed in the meantime). The Coprocessor 
Device Driver will provide emulation for the majority 
of the interrupts; however, if the Interrupt requires 
further processing, It will be routed to the Coproces- 
sor Manager or the Coprocessor Virtual Terminal 
appropriately. 

- accepts commands from the Coprocessor Man- 
ager and the Coprocessor Virtual Terminal to handle 
the coprocessor environment: 

- start, stop or reset the coprocessor 

- allow I/O for direct access devices 

- simulate interrupts 



- pass data to the coprocessor for selected trapped 
Inputs 

- terminate the coprocessor activity and release all 
resources. 

s 

COPROCESSOR ASYNC. EMULATION DEVICE 
DRIVER 

The Coprocessor Async. Emulation Device Driver 
provides routines which redirects I/O between the 

10 coprocessor and the PC async. adapter to one of the 
two planar async. ports. Data bytes containing 
control information being sent will be translated from 
the PC async. adapter format to the planar async. 
adapter format and redirected to the async. ports on 

15 the planar. Data bytes containing control information 
being received from the async. ports on the planar 
will be translated from the planar async. adapter 
format to the PC async. adapter format and 
redirected to the coprocessor. 

SO 

COPROCESSOR ONLY DEVICE DEVICE DRIVER 

The Coprocessor Only Device Device Driver 
provides for the definition, initialisation, and termina- 
tion of devices used only by the coprocessor. These 

25 routines are Invoked when the device Is defined to 
VRM and when the Coprocessor Manager attaches 
to and detaches from the device for the coproces- 
sor. This device driver does not provide any 
interfaces to control the device during normal 

30 operation. The coprocessor drives the device, di- 
rectly while the Coprocessor Manager is attached to 
the device. 

COPROCESSOR VIRTUAL TERMINALS 
35 The VRM supports 2 types of virtual termi- 
nals - High Function Terminals end Coprocessor 
Virtual Terminals. 

The Coprocessor Virtual Terminal Mode Processor 
receives keyboard input and manages the display, 

40 with the aid of off-level coprocessor device driver 
routines. Key position codes are converted to PC AT 
or PC scan codes. There are no keyboard configura- 
tion options available to the coprocessor user. 
A system display may be accessed by the coproces- 

45 sor as either a shared device or as a dedicated 
device. In the shared environment the coprocessor 
may access the display adapter in the following 
mode: 

- Monitored - The display adapter is switched bet- 
50 ween the main processor and the coprocessor via a 

hot key (ALT-ACTION). Each CPU may modify the 
adapter while in control. The screen data and 
adapter state are restored when switching between 
the two processors. All I/O commands from the 

55 coprocessor are trapped and saved to allow the 
display adapter state to be restored when control is 
returned to the coprocessor. When the display 
adapter is the PC Monochrome or the Enhanced 
Colour Graphics Adapter, the video buffer is ac- 

60 cessed directly by the coprocessor. When the 
display adapter is the IBM Advanced Monochrome 
Graphics, video buffer accesses are relocated to 
system memory and the IBM Advanced Mono- 
chrome Graphics virtual display driver is used to 

65 update the screen. 
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A system display may be dedicated to the 
coprocessor in one of two ways: 

- Direct - The coprocessor drives the system display 
directly -no relocated video or trapped I/O. The 
display cannot be switched between the main 
processor and the coprocessor via the ALT-ACTION 
key sequence. The CTL-ALT-ACTION key sequence 
Is required to terminate the coprocessor session 
and return the display to the system. 

- Allocate display to coprocessor -This is allowed 
only If there are multiple system displays and the 
main processor is not using the display to be 
allocated to the coprocessor. If the coprocessor is 
not also using another system display in direct 
mode, then the ALT-ACTION key sequence may be 
used to move around the virtual terminal ring without 
terminating the coprocessor session. 

In a system with multiple displays, the coproces- 
sor may use more than one display, however only 
one of them may be in monitored or direct mode. 
Other displays used by the coprocessor have to be 
allocated to it and made unavailable to the main 
processor for the duration of the coprocessor 
session. 

The .display configuration consists of specifying 
the following information for each display that the 
coprocessor uses: 

- the display access 

- monitored 

- direct 

- allocated 

- the display mode 

- PC mono 

- PC colour 

- the display type 

- PC monochrome adapter/monitor. 

- IBM Advanced Monochrome Graphics adapter/ 
monitor. 

- Enhanced Colour Graphics Adapter/Enhanced 
Colour Display monitor. 

- Enhanced Colour Graphics Adapter/PC mono- 
chrome monitor. 

- the primary coprocessor display. 

- the device Identifier for the adapter/monitor 
combination 

COPROCESSOR DEDICATED DEVICES 

A dedicated device is one that is allocated to the 
coprocessor for the duration of the coprocessor 
session. Except for the shared devices listed 
previously, no devices on the I/O bus may be shared. 
Configuration of the coprocessor is completed by 
declaring which I/O devices are to be attached to the 
coprocessor. For each device to be allocated to the 
coprocessor, the Coprocessor Manager will use 
VRM to allocate the device for the coprocessor. If 
the device can be used by direct I/O, then the 
Coprocessor Manager sets the trapping logic for 
that device (address) to allow the coprocessor 
direct access to the device. If the device is to be 
emulated, the Coprocessor Manager does not 
change the trapping logic on the coprocessor card. 



COPROCESSOR VRM SUBSYSTEM INITIATION 
AND TERMINATION 

The virtual machine must perform the following 
actions prior to establishing the coprocessor envi- 
5 ronment: 

1 . Issue a Define Code SVC for the Coproces- 
sor Virtual Terminal. 

2. issue a Define Code SVC and Define 
Device SVC for the Coprocessor Device Driver. 

10 3. Issue a Define Code SVC and Define 

Device SVC for the Coprocessor Async. Emula- 
tion Device Driver. 

4. Issue a Define Code SVC for the Coproces- 
sor Only Device Device Driver. 
15 5. Issue a Define Device SVC for each 

coprocessor only device. 

6. Issue a Define Code SVC and Define 
Device SVC for the Coprocessor Manager. 
The virtual machine must perform the following 
20 steps to start the coprocessor for the first time or to 
restart the coprocessor following a previous termi- 
nation of the coprocessor session: 

1. Attach to the Coprocessor Manager. 

2. Load BIOS and BASIC into memory. 
25 3. Open the coprocessor. 

4. Configure the coprocessor environment, 
using the configuration services provided by 
the Coprocessor Manager. 

5. Open a virtual terminal for the coproces- 
30 sor. 

6. Issue a command to the Coprocessor 
Manager to start the coprocessor. 

The virtual machine must perform the following 
actions to terminate a coprocessor session: 
35 1. Close the coprocessor. 

2. Close the Coprocessor Virtual Terminal. 

3. Detach from the Coprocessor Manager. 
The virtual machine must take the following steps 

to delete the coprocessor VRM support code and 
40 the coprocessor only devices from the VRM. 

1. Use the delete form of the Define Device 
SVC to delete all coprocessor only devices. 

2. Use the delete form of the Define Device 
SVC and Define Code SVC to delete the 

45 Coprocessor Only Device Device Driver and its 

associated code. 

3. Use the delete form of the Define Device 
SVC and Define Code SVC to delete the 
Coprocessor Async. Emulation Device Driver 

50 and Its associated code. 

4. Use the delete form of the Define Device 
SVC and Define Code SVC to delete the 
Coprocessor Device Driver and its associated 
code. 

55 5. Use the delete form of the Define Device 

SVC and Define Code SVC to delete the 
Coprocessor Manager and its associated code. 

6. Use the delete form of the Define Code 
SVC to delete the Coprocessor Virtual Terminal. 

60 

INTERFACES FOR VIRTUAL MACHINES 

Commands for managing the coprocessor are 
sent to the Coprocessor Manager via the Sand 
Command SVC. The virtual machine must have 
65 previously attached to the Coprocessor Manager via 
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the "Attach Device SVC." The IODN specified with 
the Send Command Is the Coprocessor Manager's 
IODN. 

Device Options Supported include: 

2 = Open the Coprocessor 

3 « Close the Coprocessor 

5 - Allocate Main Memory 

6 = Load ROM 

7 - Configure Coprocessor Display 

8 - Allocate Device to Coprocessor 

9 = Interrupt on Unallocated Device Access 

10 - Allocate Minidisk 

11 - Redirect Asynchronous Communications 
Ports 

12 = Start the Coprocessor 

13 = Set Debug Options 

These operations are performed either synchron- 
ously or asynchronously. Notification is received on 
the level and sublevel that is specified when the 
operating system attached to the Coprocessor 
Manager. 

Unsolicited interrupts are sent to the virtual 
machine when the coprocessor attempts to access 
a device that is not allocated to it. The coprocessor 
is stopped until the virtual machine resolves whether 
the coprocessor can be allowed to continue or if It 
must be terminated. An unsolicited interrupt is also 
issued to inform the virtual machine to terminate the 
coprocessor session. 

An operating system command, PCSTART, Is 
provided to the user to tailor the configuration of the 
PC AT environment. PCSTART allows the user to 
select a combination of system resources that are to 
be attached to the coprocessor. The user may 
optionally save this configuration in a default profile 
to be used in future initiations of the coprocessor. 
PCSTART also provides a prompting mode for the 
casual user, in which the user is first shown the 
current default value of a parameter and has the 
option to alter Its value. There is no memory on the 
coprocessor card, so memory Is provided as a 
mixture of system memory and I/O channel-attached 
memory. Memory is first allocated form the cards 
plugged into the I/O channel. If there is not enough 
channel-attached memory (there might not be any), 
the rest is provided form system memory and pinned 
to prevent page faults. This is accomplished by 
setting up the IOCC to convert the I/O channel 
addresses to the appropriate virtual addresses. The 
virtual addresses use the MMU segment register 
that is dedicated for I/O device access to system 
memory. Channel-attached memory must being at 
address 0 and be continuous if it is to be recognised 
and used by the coprocessor. The amount of system 
memory that is available to the coprocessor de- 
pends upon how much is left after VRM and the 
operating system have met their requirements. 

Devices connected to the I/O channel are sup- 
ported in different ways, depending on the specific 
attributes of the device. The following definitions 
describe the range of device support: 

- Main Processor Only - the device is available only 
to the main processor. 

- Shared - a device Is shared when it can either be 
accessed by both processors concurrently (e.g., 



disk, DMA) or can be dynamically switched between 
them (e.g., the display). Device sharing Is accom- 
plished by allowing only the main processor to issue 
the I/O commands to the device. 
5 - Dedicated - the device is allocated to the copro- 
cessor for the duration of the coprocessor session. 
If the device is PC AT-compatible (e.g., planar serial 
ports), coprocessor accesses to it go directly to that 
device with no intervention. If the device is not PC 

10 AT-compatible, coprocessor accesses to it are 
trapped and emulated by the main processor. 
- Coprocessor only - available only to the coproces- 
sor. Either the main processor is unable to get to It 
or the device is never allocated to the main 

15 processor. 

KEYBOARD 

The keyboard is a shared device between the main 
processor and the coprocessor. Residing in the 

20 VRM coprocessor terminal support code are a 
device driver and a mode processor that provide a 
PC AT keyboard controller interface to the copro- 
cessor. The mode processor takes in key positions 
from the VRM keyboard device driver, translates 

25 them to PC or PC AT scan codes, places them in a 
simulated keyboard buffer, and then generates an 
Interrupt to the coprocessor. The scan code sets for 
PC and for PC AT are stored in a structure indexed 
by the type of the emulated keyboard. The simulated 

30 keyboard buffer is a 1 6-byte FIFO queue with a 1 7th 
byte for overrun. 

The keyboard layout of the XX XX keys is a 
superset of a PC AT keyboard. It contains ail of the 
engravings resident of a PC AT keyboard, while 

35 some of them have been moved or duplicated to 
other key positions. For example, the new set of 
cursor motion keys and edit keys (INS, DEL, PAGE 
UP, PAGE DOWN, HOME, and END), will be 
translated as engraved, without numbers, the copro- 

40 cessor virtual terminal will maintain state flags for the 
NUMLOCK and the SHIFT keys, as well as for the 
CAPSLOCK, SCROLL LOCK, CTRL, and ALT. De- 
pending on the combined state of the NUMLOCK 
and the SHIFT, SHIFT make/breaks may be sent 

45 around the scan codes for the new native cursor 
motion and edit keys, in order to force the engraved 
key translation. 

From a system perspective, the coprocessor 
mode processor works with the VRM keyboard 

50 device driver In raw mode - receiving all makes and 
breaks of keys. During virtual terminal transitions, 
the break of keys may be sent to the next active 
terminal. Since the mode processor keeps track of 
the control/shift keys, it can send break scan codes 

55 appropriately. The mode processor also traps the 
situation where the user wishes to terminate the 
coprocessor session with the CNTL-ALT-ACTION 
key sequence. This simulates the user entering the 
PCEND command In the AIX operating system. 

60 

DISK 

The fixed disk devices on the system are divided 
into logical minidisks that are managed by the 
minidisk manager. PC AT fixed disks are emulated 
65 through the use of minidisks. Up to two minidisks 
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can be allocated to the coprocessor during a given 
session. The only Interface to the fixed disk from the 
coprocessor Is through BIOS. Any attempts to issue 
I/O instructions to the physical disk addresses are 
trapped by the coprocessor card and are interpreted 
as unallocated device accesses. 

ASYNC REDIRECTION 

There exists a coprocessor async device driver 
that will emulate serial port functions of the PC AT 
serial/parallel card on the native planar serial ports. 
I/O between the coprocessor and the PC AT 
Serial/Parallel card is redirected to one of the two 
planar async ports. Control information being sent 
will be translated from the PC AT Serial/Parallel card 
format to the planar serial port format and redirected 
to the async ports on the planar. Data bytes 
containing control Information being received from 
the async ports on the planar will be translated from 
the planar serial port format to the PC AT serial port 
format and redirected to the coprocessor. 

VIRTUAL MACHINE INTERFACES 

The coprocessor virtual terminal mode processor 
virtual machine interface has one purpose: Informa- 
tion the virtual machine that the user wishes to 
terminate the virtual terminal. The user may termi- 
nate the coprocessor by entering the PCEND shell 
command from the console, or by using the 
CTL-ALT-ACTION key sequence. The latter will 
cause the coprocessor mode processor to send an 
unsolicited interrupt to the virtual machine with a 
completion code. 

INTERFACES FOR VTRM 

The coprocessor virtual terminal mode processor 
main section is queue driven. The VTRM to CPVT 
communication consists of a Command loop com- 
prised of a queue serviced by the CPVT for 
commands from the VTRM. The queue elements 
described below are enqueued in the coprocessor 
virtual terminal mode processor command queue by 
the VTRM. 

a) CLOSE QUEUE ELEMENT: Upon receipt 
of this queue element the CPVT will take 
whatever actions are needed prior to its 
termination and acknowledge completion of 
processing this queue element to the VTRM. 

b) ACTIVATE QUEUE ELEMENT: This queue 
element is sent to Coprocessor virtual Terminal 
Mode Processor when Its virtual terminal is to 
be activated. 

For monitored mode, the Coprocessor Virtual 
Terminal Mode Processor will perform thesa func- 
tions: 

- stop coprocessor 

- activate VDD 

- If PC or Enhanced Colour Graphics Adapter 
adapter: 

- restore the display with contents of relocated video 
buffer 

- reinstate video ports 

- start the coprocessor 

For direct access to system display, the Copro- 
cessor Virtual Terminal Mode Processor will perform 
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these functions: (only a one time activation) 

- start the coprocessor 

For direct access to non-system display, the 
Coprocessor Virtual Terminal Mode Processor will 
5 perform these functions: 

- note activation. The total function of the coproces- 
sor virtual terminal during this mode, is to receive 
keystrokes from the Keyboard Device Driver and 
route them to the coprocessor, therefore, no display 

10 related action is taken. 

c) DEACTIVATE QUEUE ELEMENT: Upon 
receipt of this queue element the CPVT will stop 
the coprocessor, save off the video buffer 
contents, and save the I/O port values. 
15 This queue element is sent to Coprocessor 

Virtual Terminal Mode Processor when its 
virtual terminal is to be deactivated. This queue 
element is never sent to CPVT if in direct mode, 
since VDD Is earlier sent a command to gate off 
SO deactivate requests. 

For monitored mode, the Coprocessor Virtual 
Terminal Mode Processor will perform these func- 
tions: 

- stop coprocessor 

25 - if PC or Enhanced Colour Graphics Adapter 
adapter: 

- allocate a relocated video buffer and send address 
to coprocessor card 

- transfer display contents to this relocated video 
30 buffer 

For direct access to non-system display, the 
Coprocessor Virtual Terminal Mode Processor will 
perform: 

35 - note deactivation. No display related action is 
taken. 

The CPVT to VTRM communication consists of a 
Command loop comprised of e queue serviced by 
the VTRM for commands from the CPVT. 
AO The Coprocessor Wtual Terminal sends the 
VTRM the following queue elements: 

- CLOSE REQUEST -this queue element Is sent to 
VTRM when the CPVT has received a DETACH 
queue element from the virtual machine. This action 

45 requires the detached component to close itself out. 
CPVT will then wait for a close queue element from 
VTRM. 

INTERFACES FOR COPROCESSOR DEVICE 
50 DRIVER 

The CPDD will post the CPVT when it gets an 
interrupt from the coprocessor that warrants virtual 
terminal emulation: 

- video updates - if the display adapter is not the 
55 APA-8 Monochrome, CPD off-level process can 

handle the I/O traps and update the screen. But if 
the display adapter is the APA-8 Monochrome, CPD 
off-level process will process the I/O traps to a point, 
then will post CPVT to take care of updating the 

SO screen. CPVT needs to be called to do it since it is 
bound directly to the virtual display device driver 
(VDD) which Is used to update the APA-8 Mono- 
chrome screen. Actions to be done by CPVT would 
include calling these VDD commands: 

65 - Set Mode 
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- Set Colour Table 

- Draw Text 

- Scroll 

- Move Cursor 

- Define Cursor 

- Update ERA 

- keyboard commands 

- PC AT mode indicator(s) changed. A call is made to 
the VDD to update the state of the LEDS keyboard. 

- keyboard switch. Updates Index variable which 
points to either the PC scan code table of the PC AT 
scan code table. 

COPROCESSOR DEVICE DRIVER 

The Coprocessor Device Driver is e collection or 
routines which are used to communicate with and 
control the coprocessor adapter card. These rou- 
tines offer a cleaner interface to the coprocessor. 
Each routine is a synchronous subroutine which 
performs a specific function and then returns to the 
caller. Each of the Coprocessor Device Driver 
routines may use any other Coprocessor Device 
Driver routine except for the VRM Service routines. 
The Service routines may only be called by VRM 
Process Management. 

COPROCESSOR DEVICE DRIVER SERVICE 
ROUTINES FOR VRM 

The Coprocessor Device Driver VRM service 
routines are a set of subroutines which are necess- 
ary for any bese VRM device within the system. The 
two following routines ere required from a system 
standpoint for proper execution. These routines will 
only be called by VRM Management routines; they 
are not to be used by processes or virtual machines 
within or above the VMI. 

MAIN PROCEDURE 

CPDMAIN is the main entry point for the Copro- 
cessor Device Driver code module. This routine Is 
comprised of the following basic device driver 
functions: 

- Define Device 

This service is called when the Define Device SVC 
Is issued for the Coprocessor Device Driver Module 
by the virtual machine. At this time, the Second Level 
Interrupt Handler (SUH) is not created or attached 
to the proper Interrupt level; therefore, the interrupts 
from the coprocessor are disabled at this time. This 
precaution must be taken, since any interrupt from 
the coprocessor would go unprocessed and would 
hang the system. The input parameter for this 
routine is the DDS (Define Device Structure) which is 
taken and stored into the routine's static area. The 
DDS is then checked for validity and an error code is 
returned to VRM Is the DDD is found to be invalid. 
Otherwise, the address of where the DDS is stored 
is returned as the return code to Process Manage- 
ment. 

- Device Initialisation 

This service is called as a result of the Coproces- 
sor Manager issuing an "Attach Device" to the 
Coprocessor Device Driver. The coprocessor will be 



IPLed (i.e.. the CPD_POR routine will be called) and 
all interrupts will be blocked off. The coprocessor 
will be initialised to trap on all I/O addresses and all 
necessary video information will be set. All common 

5 data areas will also be initialised. 

As part of the VRM "Attach Device" service, the 
device's Second Level Interrupt Handler (SLIH) is 
attached to the appropriate interrupt level. The SLIH 
ID, Device ID (DID) and the Module ID (MID) can be 

10 determined and saved for future reference by 
looking in the structure passed as an input par- 
ameter to this routine, the VRM $Change function is 
called at this time in order to change the entry points 
for the SLIH and Off Level Processing routine for 

15 faster response time to the coprocessor interrupts. 

- Device Termination 

The terminate routine is called as a result of the 
Coprocessor Manager issuing an "Attach Device" 

20 with the stop option specified to VRM for the 
Coprocessor Device Driver. This service terminates 
the coprocessor application and Its support. The 
coprocessor is stopped end all resources are 
released back to the VRM. The coprocessor will be 

25 returned to the same equivalent state as when the 
Define Device routine is called. This way, the 
Coprocessor Device Driver can be attached again 
without requiring the virtual machine to issue 
another Define Device SVC. 

30 

- Exception Handler 

The Exception handler is executed whenever a 
SIGNAL (i.e., software Interrupt) is sent to the 
Coprocessor Device Driver. This routine processes 

35 timer signals sent from VRM TIMER Management 
and terminate signals from other processes. This 
routine will return a return code of (-1) any time a 
terminate signal Is received from a process. The only 
way to terminate the coprocessor is for the 

40 Coprocessor Manager to issue an "Attach Device" 
with the stop option specified. 

- I/O Initiate 

The I/O Initiate function is called when a queue 
45 element has been placed on the Coprocessor 
Device Driver's queue. The only queue element 
which the Coprocessor Device Driver should receive 
is a CONTROL element with Operations Options 
field set for "detach operation." The Coprocessor 
50 Device Driver will read the queue element and the 
dequeue the element. If any other queue element 
besides the "detach element* is received, the 
Coprocessor Device Driver will log an error and 
continue. 

55 VRM Process Management will call CPDMAIN 
with two parameters: 

1) the type of function requested and 

2) the input parameter required for the 
function called. 

60 

SECOND LEVEL INTERRUPT HANDLER (SLIH) 

The coprocessor SLIH will be called by the First 
Level Interrupt Handler (FLIH) which is attached to 
the interrupt level where the interrupt occurred. 
65 Since multiple interrupt levels can be funnelled into 



9 



BNSDOCID: <EP 0230353A2J_> 



17 o: 

one main processor interrupt level, it is necessary 
for the FUH to poll all connected SLIH's to determine 
which SLIH the Interrupt belongs to. When the 
coprocessor SLIH is first called, it will check to see if 
the coprocessor caused the Interrupt. If the copro- 
cessor is not responsible for the interrupt, then the 
SUH will return with a return code of (2). Else, the 
SLIH will process the interrupt and then return. 

The coprocessor Second Level interrupt Hand- 
ler's main function is to process interrupts asserted 
by the coprocessor card. There are five types of 
interrupts which may occur, depending upon how 
the coprocessor interrupt control register Is set. The 
five types are as follows: 

- interrupt when the coprocessor has been stopped 

- interrupt due to an I/O Trap 

- interrupt due to a relocated video buffer write 

- interrupt for video queue full/video warning 

- Interrupt when the coprocessor tried to access the 
system speaker 

Upon receiving the interrupt, the SUH will gather 
all the information from the adapter necessary for 
the complete processing of the interrupt. Otherwise, 
the SLIH will schedule the interrupt to be processed 
OFF LEVEL by returning with a return code equal to 
the address of the DDS. The Off Level Processing 
routine of the SUH will be called when there are no 
interrupts active on the interrupt level of the main 
processor. This routine will process the interrupt 
and restart the coprocessor, if the interrupt is to be 
serviced by either the Coprocessor Manager or the 
Coprocessor Virtual Terminal (i.e., data returned for 
an I/O Read Trap), the the off-level process will post 
the Coprocessor Manager or the Coprocessor 
virtual Terminal appropriately. 

The following are routines which may be used by 
Bither the Coprocessor Manager or the Coproces- 
sor Virtual Terminal. The first four offer general 
control functions of the coprocessor environment. 
The CPDDRET routine is used to return data to the 
coprocessor as part of the interrupt handling 
process for a Trapped I/O Read. CPDTRAP and 
CPDINn" are used for Initialisation purposes. 

POWER ON RESET (POR) COPROCESSOR 

This facility is used to re-IPL the coprocessor 
without having to power off or re-IPL the main 
processor. If a program is running in the coproces- 
sor, it is terminated as if the operator had turned the 
power off and back on. The processor complex (i.e., 
timers, interrupt controllers, etc.) and general state 
is reset. However, the trap logic for the I/O address 
and the video and queue Information remain un- 
changed. 

START COPROCESSOR 

This service is used to start the coprocessor. It 
can also be thought of as a Resume operation; 
therefore, the coprocessor must have been con- 
figured previous to calling this routine. This service Is 
called by both the Coprocessor Manager and the 
Coprocessor Virtual Terminal for the initial start-up 
and to continue after the coprocessor has been 
stopped. It is the responsibility of the caller to 
ensure that whatever caused the coprocessor to 
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stop has been handled, before allowing the Copro- 
cessor Device Driver to continue. 

STOP COPROCESSOR 

5 This service is used to stop the coprocessor. This 
service is called by both the Coprocessor Manager 
and the Coprocessor Virtual Terminal to stop the 
coprocessor for device changes that require an 
externally generated (but temporary) stop in activity. 

10 It is the responsibility of the caller to ensure that 
whatever caused the coprocessor to stop has been 
handled before allowing the coprocessor to con- 
tinue. 

15 SIMULATE INTERRUPT TO COPROCESSOR 

This routine allows the caller to assert an interrupt 
on a specific interrupt level to the coprocessor. The 
Coprocessor Virtual Terminal, for example, will use 
this routine to simulate a keyboard Interrupt to the 

SO coprocessor. The Coprocessor Async. Emulation 
Device Driver will call this routine to simulate an 
interrupt from the Planar Async ports. 

TRAP I/O READ DATA RETURN 

25 This routine is indirectly part of the interrupt 
handling process. When the coprocessor issues a 
Read to an I/O address which is trapped, the 
coprocessor asserts the interrupt line. As a result of 
the interrupt, the CPD OFF LEVEL routine Is 

30 executed. This will determine where the coproces- 
sor is trying to read and who should return the data. 
If the Coprocessor Manager or the Coprocessor 
Virtual Terminal are responsible for the port, then the 
respective component will be signalled. When the 

35 Coprocessor Manager or the Coprocessor Virtual 
Terminal have acquired the requested data, they 
then call this routine to pass the data to the 
coprocessor. Once the data Is written to the 
coprocessor, the trap is cleared and the coproces- 

40 sor is allowed to proceed. 

TRAP I/O SET/RESET 

The catling process uses this routine to inform the 
coprocessor how to Interpret each I/O address of 
45 the 64K available I/O addresses. Starting at zero, 
each group of 8 addresses can be set for one of the 
following actions: 

- Allow coprocessor direct access to this port (no 
trap) 

50 - Trap and ignore or Trap and remind Coprocessor 
Manager to Interrupt virtual machine. 

- Trap and Inform Coprocessor Manager. 

- Trap and inform Coprocessor Virtual Terminal. 

- Trap and emulate by Coprocessor Device Driver. 
55 Upon initialisation, the coprocessor will be set to 

trap on all I/O addresses. The Coprocessor Manager 
and the Coprocessor Virtual Terminal may then set 
which ports should be allowed access to. The call to 
the Coprocessor Device Driver is: 

60 

CALL CPDTRAP (Start-addr. Length. Set-flag) 

INITIALISE/TERMINATE COPROCESSOR 
This facility is used by the Coprocessor Devica 
fi5 Driver Main procedure to initialise the COPROCES- 
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SOR adapter card. This procedure is also used by 
the Coprocessor Manager to terminate the session. 
The coprocessor application will be halted and the 
COPROCESSOR adapter will be PORed. The trap 
logic will be reset to trap on all addresses and the 5 
video and queue parameters will be reset to the 
default values. 

POSTS TO COPROCESSOR MANAGER AND 
COPROCESSOR VIRTUAL TERMINAL 10 

Posts will be used as a means of asynchronous 
communications between the coprocessor VRM 
components. Each COPROCESSOR component 
upon receiving an Event Control Block (ECB) via the 
Post, will be required to update the appropriate 15 
section within the COPROCESSOR Event Block 
(CEB) as shown in Fig. 5. The CEB Is part of the 
COPROCESSOR VRM components' common data 
area. The CEB may be read by any COPROCESSOR 
component for valuable information relating to SO 
current operations. The CEB will also be passed up 
to the Virtual Machine as part of the Query Device 
Structure for a Query Device SVC. 

While Ihe invention has been particularly shown 
and described with reference to a preferred embodi- 25 
ment thereof, It will be understood by those persons 
skilled in the art, that various changes in the form 
and detail may be made without departing from the 
scope of the appended claims. 



Claims 

1. A method for managing the operation of a 35 
coprocessor in a virtual memory virtual machine 

data processing system which Includes a Virtual 
Resource Manager (VRM) consisting of a 
plurality of interrelated programming compo- 
nents which are executed on the main proces- 40 
sor to establish virtual machines for executing 
various application programs concurrently, the 
VRM assigning system resources, including 
one of a plurality of operating systems, to each 
of the virtual machines, including establishing, 45 
in the VRM. a coprocessor programming sub- 
system component comprising a plurality of 
programming subcomponents which function 
to define a virtual machine Interface to the 
coprocessor and executing the subsystem 50 
component to permit the coprocessor to pro- 
cess an application program under the control 
of an operating system that is run by the main 
processor. 

2. A method as claimed in Claim 1 , where the 55 
data processing system includes an Input/Out- 
put Channel (I/O) and an I/O Channel Control- 
ler, further including establishing an information 
transfer path between the coprocessor and the 
main processor which includes the I/O Channel bo 
and the I/O Channel Controller. 

3. A method as claimed In Claim 2, where the 
data processing system includes a plurality of 
I/O devices connected to the I/O channels, 
further including assigning selected I/O devices 65 



to a virtual machine executing programs on the 
coprocessor. 

4. A method as claimed in Claim 3, where the 
system Includes a system memory and a 
Memory Manager Unit and additional memory 
attached to the I/O Channel for exclusive use by 
the coprocessor, further including transferring 
data between the coprocessor and the system 
memory during execution of programs by the 
virtual machine. 

5. A method as claimed in Claim 4, where the 
architecture of the coprocessor is different 
from that of the main processor and at least one 
of the I/O devices has operating characteristics 
that are incompatible with the architecture of 
the coprocessor, further including assigning 
the one I/O device to the virtual machine 
employing the coprocessor, and using the main 
processor to correlate the data transferring 
operations between the one I/O device and the 
coprocessor. 

6. A method as claimed In Claim 5 in whfch 
the correlating further Includes simulating con- 
trol signals to the coprocessor and to the one 
device to take advantage of at least one of the 
operating characteristics that are normally 
incompatible with the architecture of the copro- 

7. A method as claimed In Claim 6 In which 
the coprocessor has an architecture which 
permits running a DOS operating system and 
any application program that can be run under a 
DOS operating system. 

8. A virtual memory virtual machine data 
processing system which includes a main 
processor, a coprocessor, a Virtual Resource 
Manager (VRM) consisting of a plurality of 
interrelated programming components which 
are executed on the main processor to estab- 
lish virtual machines for executing various 
application programs concurrently, the VRM 
assigning system resources, including one of a 
plurality of operating systems, to each of the 
virtual machines, including establishing, in the 
VRM, a coprocessor programming subsystem 
component comprising a plurality of programm- 
ing subcomponents which function to define a 
virtual machine interface to the coprocessor 
and executing the subsystem component to 
permit the coprocessor to process an applica- 
tion program under the control of an operating 
system that is run by the main processor. 

9. A system as claimed in claim 8 in which the 
coprocessor Is mounted on an integrated 
circuit card which is inserted into a 'mother 
board' socket which contains the main proces- 
sor and related components. 
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